Processional Data Engineer

Coursera やりながらのメモ

Processional Data Engineer

Google Cloud Big Data and Machine Learning Fundamentals

Networking & Security < Compute & Storage < BigData and ML Products みたいな階層、問題にでそ〜

アクセス頻度から Cloud Storage の Storage Class 選ぶやつ、中途半端なやつでたらいやだな

4V = 多様性（Variety）、ボリューム（Volume） 速度（Velocity）、正確性（Veracity）

結構 Dataflow 押しだなあ

SQL の S って Structured なんだ

BQML の LTV 予測

High Value Customer かどうかの Classification なのね

BQ で 1 hot encoding

ML.FEATURE_INFO()

ML.WEIGHTS()

shop.googlemerchandisestore.com の購買データを使えるのおもしろい

data-to-insights プロジェクト

identifying and marketing to these future customers based on the characteristics of their first visit will increase conversion rates and reduce the outflow to competitor sites.

after a visitor's first session、セッション開始時点で visitorId は分かるやろと思ったけど after の解釈に依る

visitId も分かるのが正解、after ... session starts やね

It's often too early to tell before training and evaluating the model,

おー一見だめそうだけどこれで行くんだ

曲線の下の面積が大きい ≒ 1.0 に近い = 良い

不均衡データの評価はデータの偏りが反映されがちなので注意という話

https://gyazo.com/3c97c62f63bdd2d76895885db432d83b

テキストのクエリ切れてる! リロードしたら直った...

12ヶ月のデータの 9ヶ月を学習、2ヶ月を評価、1ヶ月を予測に使っている

~ というタスクがあってどのモデルを使うか、という問題

4 Options

AutoML

転移学習する

table とかでもそうなの?

Neural Architect Search

ノーコード

Vertex AI Workbench

カスタムトレーニングするのに便利

Pre-built container

色々ライブラリ入ったコンテナが使えるのかな?

便利そうではある

マネージド Colab と違うのか?

Vertex AI

開発から本番環境へのデプロイ & モニタリング

Feature Store

CCAI = Contact Center AI

Q. あなたは動画制作会社で働いており、機械学習を使用してイベントの映像を分類したいと考えています。独自の機械学習モデルをトレーニングするには、どれが役立ちますか。

これって事前構築済み API なんだ......

AutoML でもない

Offline Prediction とかできるの

モデルを Export するやつ?

適合率重視か再現率重視かを問う問題がでる

潜在的な患者をできるだけ多く特定する → 再現率

不良品のりんごだけ特定して無駄にならないようにする → 適合率

データの準備 → トレーニング → モデルの提供

特徴量エンジニアリングは準備扱い

評価はトレーニング

Vertex AI Pipelines

オーケストレーション、自動化、モニタリングまでやる

めちゃ良いページ

Modernizing Data Lakes and Data Warehouses with GCP

データパイプライン

アクセス

品質

計算リソース

クエリパフォーマンス

データレイク

すべてのデータタイプに対応できるか

スケールするか

high-throughput ingestion

きめ細かいアクセスコントロール

簡単に他のツールから接続できるか

データウェアハウス

バッチ or ストリーミング

スケールするか

カタログ & アクセスコントロール

クエリ費用は誰が負担するか?

保守レベル

他チームとの連携

ML

DWH まで到着する時間

列を追加する難易度

Analysit

スキーマが明確に定義されたデータセット & 列のプレビュー

他のデータエンジニア

信頼性・健全性・モニタリング

DLP API

Productionalize

パイプラインの健全性

データのクリーンさ

稼働時間の最大化

スキーマの変化への対応

データエンジニアの役割、"データに新たな価値を加える" も入るのね

パイプラインとオーケストレーションレイヤ

data sink

目的地

Logging の Sink やね

Cloud Storage

マルチリージョンならリージョン間、シングルリージョンならゾーン間でレプリカ

複数のリクエストが異なるレプリカから

Standard > Nearline > Coldline > Archive / 30 > 90 > 365 か意外と覚えやすいな、間がクイズにでてもいけそう

ファイルシステムだとディレクトリ間のコピーだけど bucket + key なので列挙はファイル数で O(n) 的な話

閲覧権限、IAM と ACL

暗号化とロック

暗号化 GMEC / CMEK / CSEK

ロックは改ざん・削除を防ぐ

この辺普段気にしない割に問題にしやすそうだな...

DWH は 集約 consolidate

BigQuery

どうせ知っとるわ〜と思いきや Google Cloud の中のコンポーネントの名前がぽんぽん出てくるサービス回

Jupiter: peta bit network

Colossus: storage engine

Capacitor: Storage format

デモ

これやな

Slot time consumed 時間分の処理が分散実行されてる

これ一通り読むと面白そう

de-normalize

nested and repeated

正規化されたテーブル → JOIN のコスト

1つの大きなテーブル → だと粒度の扱いを気にする

nested & repeated なカラムを使おうという話

テーブルが 10GB 未満なら JOIN でいいんじゃないという話

パーティションフィールドは 比較の左辺に単独で置きます 不要なパーティションが すばやく破棄されるようにするためです

あんま気にしてなかったな

クラスタカラムは LIKE と REGEX の prefix search でも効く

クラスタリング列の順序

再クラスタリングが定期的に行われる

昔はテーブルを変更するオペレーションしているとデータの並びが不完全になっていってたの

fake_date に NULL 入れて1つのパーティションの中でクラスタリングする

問題全然分からんと思ったけど "正しくないものはどれですか" だった〜〜〜

Building Batch Data Pipelines on GCP

EL, ELT, ETL

EL: データが既にクリーンで正確の場合

Cloud Storage → Cloud Composer / Cloud Functions で読み込みを kick

ETL が必要な例

SQL でできない or 複雑すぎる処理、翻訳 API を叩くなど

Data Quality

Valid / Accurate /Complete / Consistent / Uniform

Spark & Hadoop 資産を使うなら Dataproc / GUI でなんかやりたいなら Data Fusion

Lineage

Label(Key + Value) をつけて DataCatalog で管理しようという話

Hadoop エコシステム

Dataproc Cluster

Nodes

Workers

Secondary Worker

HDFS: Storage

Persistent Disk or Cloud Storage via connector

Setup → Configure → Optimize → Utilize → Monitor のステップ

あんま興味ない話が続く

データの局所性があるといいよねそりゃそうだね

Local HDFS

メタデータ操作が必要、データを更新したり追記したり rename する場合

Cloud Storage の特性の合わないなら Local HDFS やね

データのソースと最終的な出力を Cloud Storage にするとよいという話

中間データを Local HDFS で加工しながらやる

Dataproc は

Spark & Hadoop のマネージドクラスタ & HDFS なしでジョブ固有のクラスタを作成しやすい

Cloud Storage と直接の read & write して Computing と Storage を分離

ラボ

hadoop fs コマンドで csv をコピーして SqlContext でクエリ

積極的に使いたくないけどまだ興味ある

batch と stream で同じコードを使える

Pipeline / PCollections / PTransforms / Pipeline runners

PCollections ではすべてのデータ型がシリアライズされたバイト列としてやりとりされる

グラフの最適化、自動スケーリング

? PubSub からの入力、ローカルの DefaultRunner で動くんだろうか?

beam.ParDo(function extends beam.DoFn)

beam.CombineFn

code:averagefn.py

class AverageFn(beam.CombineFn):

def create_accumulator(self):

return (0.0, 0)

def add_input(self, sum_count, input):

(sum, count) = sum_count

return sum + input, count + 1

def merge_accumulators(self, accumulators):

sums, counts = zip(*accumulators)

return sum(sums), sum(counts)

def extract_output(self, sumu_count):

(sum, count) = sum_count

return sum / count if count else float('NaN')

Combine と GroupByKey

GroupByKey は Key ごとに 1ワーカー必要

Combine は計算を 可換 & 結合的 に定義してばらばらに実行できる

Flatten は UNION 的な感じ

Partition は PCollection を分割する

四分位でやる例

副入力(side input)とデータウィンドウ

実行時期に決まる値や、他のパイプラインからくる値と組み合わせる場合

Transform は1アイテムごとに発生する変換 & 最後に発生するパート

最後の値が分からない場合 = ストリーミング

グローバルウィンドウとタイムベースウィンドウ

beam.WindowInto (beam.window.SlidingWindows (60, 30))

スライディングウィンドウ、60秒間キャプチャしつつ30秒ごとにウィンドウを開始する

DataFusion

ラボ: Wrangler でデータ眺める

Cloud Composer

schedule base / trigger base

これ GKE にたつのか & UI は AppEngine? appspot.com を再利用しているだけ?

Dataproc のクラスタ作って wordcount してクラスタ消す

なんかすごいな

PubSub

普段使ってるから勘でクリア出切ると思う

HIPAA 準拠云々

Filter

メッセージ保持

期間 7 日、replay もそこまで戻れる

サブスクリプションを作る前に Publish されたメッセージを replay することもできる

メッセージのストレージは Topic の所属するプロジェクトに付く

デッドレターキューとエラーロギング

順序、重複の扱い

Dataflow でカバーする

Dataflow は、膨大な量のデータを操作する際に復元性の高いストリーミング パイプラインを容易に作成できる次の機能を備えている。（正しい回答を 2 つすべて選択してください）

めちゃくちゃ悪問だと思うが...

https://gyazo.com/6bd8442f3b9fbcccda26e892efe5778e

Pub/Sub トピックとサブスクリプションに関する次の説明のうち、正しいものはどれですか。（正しい回答を 2 つすべて選択してください）

選択肢の日本語が良くなくて難しすぎ

https://gyazo.com/ea39b8e7a208d366553b855eaeacddc9

総当り的にやってこれが正解っぽい...

なにが良くないか

ここのPublisher & Subscriber の助数詞は 人 じゃないだろ

"サブスクリプションからリクエスト可能" とは?

push と捉えると 1 subscription ごとに push 先URL は 1 つ、裏に複数台にすることはできるが

複数の subscriber が同じ subscription から pull することはできる、これを指していると思うが...

3つ目は意味がわからない

各トピックは subscription ごとにすべてのメッセージを配信する(複数の subscription がある時に割り振るわけではない、subscription 個別にキューがある動作モデル)、と解釈するなら正しい

4つ目も微妙

subscription がないと実質機能しないので必要と言える

後から subscription を追加しても追加以後に publish したメッセージしか流れない(過去に seek して replay すれば流せるが...)

topic 自体は作成できるが、デフォルトでは subscription がないと7日? とかで消える

ordering key 機能はあるし exactly once オプションは出つつあるし...

Dataflow with Streaming

ウィンドウごとに集計する

メッセージのデータからタイムスタンプを読み取って PCollection 中のデータの時刻にする

TimestampedValue

過去 10 分のカスタムIDのリストを Dataflow で維持して重複排除

まあ想像どおりやな

3種類のウィンドウ

固定、スライディングウィンドウ、セッションウィンドウ

https://gyazo.com/9a06c5ff566bbd9c2c45f02421830347

スライディングは重複期間で移動平均を出すなど

最小ギャップ期間

セッション

ユーザが何ページが閲覧して去る、みたいな動作イメージ

timeout 期間がすぎるとその key が flush される

遅延への対処

理想的には時計で flush して閉じる

待つべき時間 = ウォーターマーク を Dataflow が追跡する

Pub/Sub コネクタなら、最も古い未処理のメッセージと Dataflow で処理された最新のメッセージを把握してラグを計算して待つ(遅延が 3~4 秒なら Dataflow は 4秒待つ)

それ以上遅れた場合はどうするか

デフォルトでは破棄

遅延に基づいてウィンドウを再処理

トリガー

次の処理を起動させる?

デフォルトは AfterWatermark

遅延を考慮しつつデータの時刻ごとにトリガー

AfterProcessingTime

AfterCount

データ量で一定貯まるとトリガー

ストリーミング処理のいい命名やら仕組みがいろいろあるね

トリガーの組み合わせ

code:combine-trigger.py

pcollection | WindowInto(

SlidingWindow(60, 5), // 60秒ウィンドウを5秒ごとに開始

trigger=AfterWatermark(

early=AfterProcessingTime(delay=30), // パイプラインに入ってから30秒経過したら開始

late=AfterCount(1)), // 遅延したデータはデータごとに処理

accumulation_mode=AccumulationMode.ACCUMULATING,

allowed_lateness=Duration(seconds=2*24*60*60))

ラボ

Dataflow で PubSubIO 使うと subscription が生えてくる

行を LaneInfo にして方向とか計算してるのおもしろい(入力そのままぽいけど)

おもしろいし便利なのだが、遅延どうするかの問題がダルそうすぎる

https://gyazo.com/81494be6de3382ac8fe2500cd659aedd

FOR SYSTEM_TIME AS OF

しれっと time travel だ!! スゲー

BigTable

BigQuery のレイテンシが問題になる場合

10MB 以下の非構造化 Key-Value 向け

向いてないもの

高度に構造化されたデータやトランザクションデータ

1TB 未満

SQL に似たものや JOIN が必要なもの

ストレージ Colossus

Tablets > Data

ホットスポットを検出して Tablet を分割する

行キーのみ

Scan: キーを1回なめれば集まる

Sort: 並べ替えが発生する

Search: 列を参照して集める

実行したいクエリにあわせて行キーに情報を詰める話

Column Families

100 まで

単にカラム名の prefix というわけではなく、効率に関わるのか

１つ以上の列ファミリーから データを取得する方が 行から取得するより効率的です

ソート順に合わせて事前に値を調整する

降順なら INT_MAX - epochした値を入れておくなど

削除マーク

削除は削除マークがつく

Mutation も追記と削除マーク

定期的に実際に削除する & アクセスパターンからデータをバランスさせる

ノード間で tablet を移動させる

スキーマ設計

ワークロードにあわせたスキーマ設計

アクセスパターンを学習する時間が必要

ノード数が少なすぎる

ノード間でバランスさせるのに最大20分

行のセル数が少ないほうがよい

KeyVisualizer

これ Firestore にもあるやつだ!!

見方が全然わからんが

ラボ

BigTable instance 作るの早すぎない?

code:scan

hbase(main):001:0> scan 'current_conditions', {'LIMIT' => 2}

ROW COLUMN+CELL

15#S#1#9223370811323875807 column=lane:direction, timestamp=1225530900, value=S

15#S#1#9223370811323875807 column=lane:highway, timestamp=1225530900, value=15

15#S#1#9223370811323875807 column=lane:lane, timestamp=1225530900, value=1.0

ほぉ〜

code:scan2

scan 'current_conditions', {'LIMIT' => 10, STARTROW => '15#S#1', ENDROW => '15#S#999', COLUMN => 'lane:speed'}

STARTROW ~ ENDROW までを取ってくるためね

これ Firestore で prefix search する時にもやるな

https://gyazo.com/d5a03a47a5017ba848437f6d1a5aff8c

SQL に対応していないから選んだけど、1TB 未満は向いてないんじゃないの → これで正解

Bigtableが向いていないのは 高度に構造化されたデータや トランザクションデータ 1TB未満の小容量データ SQLクエリやSQLに似たjoinが必要なものです

え~~???

英語字幕も探す...

Bigtable is not well suited for highly structured data, transactional data, small data volumes less than 1TB, ...

言っとる

BigQuery 分析ウィンドウ関数

余裕で分かるけど、この関数はどのグループ? みたいなの聞かれたら困るな

Standard aggregations

COUNT, SUM, COUNTIF,

Navigation functions

FIRST_VALUE, LEAD, LAG, ...

Ranking & Numbering functions

RANK, ROW_NUMBER

GIS 関数う

ST_GeogPoint, ST_DWithin, ST_GeogFromGeoJSON,

SELECT STRUCT(...) AS ...

GIS ビジュアライザ

これええやん

automatic predicate push down

自動述語プッシュダウン

WKT(Well-Known Text)

BigQuery Performance

5要素

I/O

読むデータサイズ

Shuffling

次のステージにどれだけ渡すか

Grouping

グループごとのデータサイズ

Materialization

書かれるデータサイズ

Functions and UDFs

どれだけ CPU を使うか

SELECT * しない

WHERE で早く頻繁にフィルタする

ORDER は最後だけ

JOIN は大きなテーブルを左に、最適化しやすくなる

GROUP BY はカーディナリティを低く使う

パーティショニング

クラスタリング

パーティション内でクラスタ化される

クラスタ列の順序

実行計画

Rows で行数読む

Cloud Monitoring で Slot utilization を見る

90日テーブルが編集されない場合は long time storage

リセットされる

テーブルへのデータの読み込み

テーブルへのデータのコピー

テーブルへのクエリ結果の書き込み

データ操作言語の使用 データ定義言語の使用

テーブルへのデータのストリーミング

リセットされない

テーブルのクエリ

テーブルクエリのビューの作成

テーブルからのデータのエクスポート

別の宛先テーブルへのテーブルのコピー

テーブルリソースのパッチ適用または更新

Slot

複雑なクエリを大量に投げる状況ならスロット容量を増やすことでパフォーマンスが上がるかも

500スロット単位で購入

Flex Slots は短時間のスロット購入、1スロット 0.04/h で 100 スロット単位で購入

60秒後にキャンセルできる

月間コミットメントは30日間キャンセルできない、その後キャンセルすると秒割

同時実行するクエリ間でスロット割当を分割して実行する

オンデマンドではプロジェクトで最大 2000 スロット

ストリーミング分析システム

取り込みデータ量の変動に対処できることが必要

データからリアルタイムに分析情報を引き出せるように

PubSub → Dataflow → BigQuery

うーむ

https://gyazo.com/d5041afc586d27dfa59c0eb023adb0d4

クソ問 of クソ問では...

非構造化データ

Dialog Flow 使ってみたい

Notebooks

ハードウェアを簡単に変更でき GPU の追加や削除も可能

JupyterLab の最新の OSS バージョンを仕様している

個々のプロジェクトの Compute Engine インスタンスである

最新の ML ライブラリをインストールするかは任意 ← これは❌

BQ のマジック関数が含まれている

? Managed と User-Managed どう違う?

Kubeflow

ラボ

ここは sed で置換させるんだ

deploymentSpec

command

終わり!?

AI Hub のテンプレートの種類

BQML

ML.EVALUATE

log_loss

BQML で k-means できたのか、便利やん

ラボ

duration is not null いれんといけんとちゃうか

CREATE MODEL に TRANSFORM 句を追加して入力側で変換するのではなくモデル側に変換ロジック持たせられる、これええやん

Matrix Factorization 動かせる!! と思ったけど学習済みモデル使うんかーーい

AutoML

まあはい

AutoML Vision

最多のラベルが最少のラベルの100倍程度が望ましい

少なすぎるものは削除するとよい

Vision, Natural Language, Table

AutoML と BQML の使い分けの表

AutoML で使用するものは? → Google のモデルと自社データ

データ表現

問題文に Row や Column があれば SQL 系、Entity や Kind → Datastore みたいな話

NUMERIC と丸め誤差

Spark の RDD(Resilient Distributed Datasets) はデータの配置やレプリカの詳細を抽象化して隠している

Dataflow は PCollection

Tensor Flow

サブネットはリージョン以下のリソース? ゾーンまたがって定義できるかどうか

パイプライン

Dataproc は Hadoop のパイプライン

クラスタ外部にデータを置いている場合、使っていないときにシャットダウンできる

ジョブや作業カテゴリごとにクラスタを起動できるようになる

ジョブを効率よく実行できるように調整が必要 & コストに見合うように使用する

Spark は RDD → RDD

周辺ツールを GCP で置き換える話

Kafka → Pub/Sub

HBase → BigTable

HDFS → Cloud Storage

Dataproc のアクセス制御はクラスタへのアクセス

Dataflow は Beam

副入力の話

Dataflow はロール設定でアクセス制御

GroupByKey は実行コストが高くなりがち

BigQuery へのストリーミング Dataflow、Logging、API

PubSub のメッセージ保持期間は最大7日

疎結合にしてピークにあわせたインフラを用意する必要がなくなる話

データ処理システムの構築

ACID

これはわかる

Atomicity / Consistency / Isolation / Durability

BASE

Availability の話

Basically Available / Soft state /Eventual consistency(結果整合性)

Cloud Storage いろいろ機能があり見逃されがちという話

Spanner と CloudSQL は グローバルスケールさせるかどうか

構築と保守

問題がおきるのはメッセージのレイテンシ・順序の問題

Dataflow で重複排除して並べようという話

BigQuery は Cloud Storage とそう変わらないストレージコストなのでそのまま保管する選択肢がある

Spanner に比べて Bigtable コスト安い

BigTable は 10 node で 100,000qps さばけるが Spanner は 150 node 必要

Spanner CPU 使用率モニタリングしてノード増やす話

Analyzing & Modeling

Natural Language API

感情分析・エンティティ・構文

人間による解決が最適な1回限りの問題 / 大量のデータを処理することで解決できるビックデータの問題 / モデルによる解決が最適である機械学習の問題を区別

MSE / RMSE

クロスエントロピー → 分類問題

完全正より実用性という話

データが足りない → 独立したテストデータ または 交差検証

パフォーマンス

Business Requirement / Technical Requirement

PDE Prep の Dataproc やるやつ

Dataproc 全然興味ないけどクラスタのノードスケールアップさせたり台数増やしたりしててたのしい

セキュリティとコンプライアンス

プライバシー、認証と認可、IDとアクセスの管理、侵入検知、攻撃の軽減、復元力、障害復旧まで含まれる場合がある

閲覧を設定できる単位は、DB インスタンスなのか 行なのか列なのか... etc

bigquery.resultonly.viewer なんて存在しないロールが選択肢に出てきて結構引っ掛けだな~~~

これええやん

模擬試験1

Transfer Appliance って何!?

Snowball 的なやつか

Strage Transfer Service と Transfer Appliance の使い分け

IoT Core is 何!?

IoT デバイスからリクエスト受ける前段に置く

Partner Interconnect

86.95%

"フォーマット ファイルを指定し" って AVRO とかのあれか!!

cbt ツール何できるのか?

BigTable で外れ値見れる?

テス勉

CloudSQL で公開 IP アドレスあるなら IAM 認証使うのがだいたい適している

BigTable で HDD 使う状況

レイテンシ気にしない・10TB 以上のデータ

BigQuery の予算を守るには割り当て調整する、ガイドラインや確認できるようにするのは遵守する必要が遺る

これ知識がないビジネスアナリストじゃなければ結果変わる? 別に割当でいい気も

MongoDB Atlas しらねぇ〜でもまあ Marketplace でしょという選択肢

暗号方法

だれもアクセスできないようにする、ならクライアントサイドで暗号化

BigQuery の quotaExceeded

MERGE つかうのが正答らしい、うーーん

CPU or TPU or GPU

柔軟性が必要・プロトタイピング → CPU

CPU 上で部分的に実行しなければいけない演算がある → GPU

TPU で実行できない演算 → GPU(そりゃそうじゃ)

行列計算がメイン → TPU

カスタム TF 演算がない → TPU

Hadoop クラスタでキャリブレーションする話

処理の前にキャリブレーション入れる

MapReduce ジョブは1つの目的に対して1つ作るべき

Hadoop の機能の話

知らねえしムズすぎ

チェックポイントと分割パイプライン → Pig Latin

コスト効率、にどこまで入れるのか問題

BigTable のストレージを変えるにはバックアップ機能で移行する

インスタンス内ではストレージ変えられない

BigTable は tablet を分散して保存する & 移動させる → 肥大化に備えてストレージ容量を監視する

BigQuery のタイムトラベルは 7日が MAX

BigQuery が提供するのは "ストレージと分析" 、"ストレージとコンピューティング" はバツ

4V = 多様性（Variety）、ボリューム（Volume） 速度（Velocity）、正確性（Veracity）

Spanner のパフォーマンス問題

親子関係にあるやつはインターリーブさせる

主キーのホットスポット避ける

連番や時刻を避ける

インデックス貼る

他にも出る問題ある?

BigTable のキー設計問題

何で検索するかでだいたい2択になる

ホットスポット起きないようにする

タイムスタンプのみ、または先頭にタイムスタンプを持つことは推奨されてないので選択から外す

キー以外の BigTable パフォーマンス問題は

ノード数増やす & ストレージSSD にするのが主

書き込みと読み取りを分散させる

DB プロダクト選択問題

まあオレには難しくない

グローバルスケールありなら Spanner

高レートや数百万オーダーなら BigTable

既存のオンプレを費用を同レベルか削減するなら CloudSQL

トランザクション必要 & サイズ小さめ(<500GB)なら CloudSQL

Cloud SQL はリージョン横断リードレプリカ作れる

400GB 以上の RAM、30TB のストレージいける

自動スケールアップできる

Spanner or CloudSQL

それ Spanner でいいんじゃねと言いたくなるも、グローバルスケールへの言及がない & CloudSQL 上限以下なら CloudSQL が正解

BigTable を分析に使う

クラスタレプリケーションでプロファイル分けて一方を分析に使う

CloudSQL or Datastore の状況ではデータが爆発的に増える → Datastore かなあ

大容量データ転送の選択問題

だいたいショットのもの(ファイルサーバー)を Transfer Appliance で転送した後どうするかの話

10TBの転送にTransferApplianceするの時間効率いいか?

問題としてはいいらしい、目安: データサイズが 10 TB 以上である

注文→配送→データコピー→配送→設置 の間に10TBぐらい送れない? 1w はかかるでしょ

定期的に大量に送るなら専用のネットワーク接続も聞かれる、帯域幅で決める

大量 = 30Gbps = Dedicated Interconnect & Partner Interconnect

Cloud Interconnect の下に Dedicated / Partner がある

Dedicated はオンプレと繋ぐ、Partner はサポートプロバイダとの連携

VPN は少量の転送 → 1.5~3GBps

Partner Interconnect は 50 Mbps ~ 50 Gbps (< 10Gbps) & ISP の SLA が適用

Dedicated Interconnect は 10~80 Gbps

VPC ネットワークピアリングは Google Cloud 内の転送

Storage Transfer Service は S3 などからの転送

データパイプラインプロダクト選択問題

これもほぼ要件のキーワードで決まる

Apache Spark、Presto、Apache Flink、Apache Hadoop → Dataproc

Apache Beam やストリーミング加工 → Dataflow

PubSub のスキーマで BigQuery に入れりゃいいやんというのもこれになりがちではある

Dataprep

Dataflow テンプレートとしてエクスポートして Cloud Composer から呼べる

BigQuery

ML 製品選択問題

問題文によって微妙なラインでしょというのがあると思うなあこれは

基本的な難易度や要求されるデータ数は

AutoML < BQML < 自前のカスタムモデル

要件によって構築済み API を採用する

データ数が多くない → AutoML

BigQuery に 6000 行のデータ & 200 ラベルの時は少ない扱い、BQML ではなく AutoML を使うのが正答

画像なら カテゴリ, ラベルごとに100枚程度 → AutoML

他の人とコラボレーションが出たら基本 Workbench

PubSub 使い方問題

システム負荷を下げる/均一化するなら pull

アプリケーションがオンラインではない場合も考える → pull

PubSub → Dataflow で、タイムスタンプベースでデキューできる

処理順序に基づくなにかがある時

保持期間7日

BigQuery コスト最適化問題

主に、SELECT するカラムを減らす、パーティション効かせる

ビューは都度クエリを実行するのでコストがかかる

繰り返し読む & コスト厳しいなら非正規化したり加工したりする

BigQuery パフォーマンス問題

更新が激しいならマテビュー

BigQuery スロットを予約してもパフォーマンスは向上しない

外部テーブルで遅いならネイティブテーブルにする

Hive パーティショニングとか出るか??

Dataproc のパフォーマンスや費用の問題

永続データを Cloud Storage において使ってない時はシャットダウン

Compute Engine に置くのはまあない

時間の短縮ならワーカーを増やしてよい / 費用最適化なら基本ふやさない

正常なデコミッションのタイムアウトをクラスタが処理する最長ジョブよりも長い値に設定

既存のクラスタのマシンタイプを変更した垂直スケールはできない

たいてい制約の中で水平スケールさせる(台数を増やす)

グレースフルデコミッショニング

Spark で Parquet ファイルを使用する場合のファイルサイズの目安は 1GB

Hadoop でローカル HDFS を使う状況 = Cloud Storage で実行コストが高くなる時

多くのメタデータ操作が必要、削除やディレクトリ名の変更など高コストな操作が必要、ファイルに追記する

ML でどうするか抽象的な質問されるやつ

テストでは適切だけど実世界ではだめ → 過学習

正則化・ドロップアウト

NN レイヤや特徴を減らす

性能が低い、訓練セットの誤差が(テストより)大きい → 学習不足

モデルの複雑さが足りないのでデータ増やす、特徴量追加する

データ量が少ない

クロスバリデーション

教師なし学習は基本的にクラスタリングだけ想像して答えればよい

特定の特徴量が重要なことが分かっているときは L1 正則化

雑な判断な気がするが...

転移学習云々が出たら AutoML

コストかけて良い・要求が高いならカスタムトレーニング

Dataflow 使い方

Key ごとにワーカー必要な GroupByKey より Combine のほうが効率良い話

Partition で PCおっぇcちおn を分割する

Dataflow ウィンドウの話

非グローバルウィンドウ関数・非デフォルト関数を使って失敗

Apache Beam では 固定ウィンドウ・スライディングウィンドウ・セッションウィンドウ

Dataflow では タンブリング・ホッピング・セッション

エラーハンドリング

sideOutput で PCollection にエラーだして PubSub に入れ直す話

うーんログのほうが取り回しやすいと思っちゃうけどなあ PubSub メッセージ残る期間7日でしょ?

実行中のパイプラインの更新

ドレインは処理がバッファ内の処理が完了してから取り込みが止まる、ストリーミングのみ

ストリーミングで入力に PubSub 入ってると言われてなくてもドレインで停止していい世界観なのか? うーん

遅延への対処

ウォーターマークである程度は良い感じに / トリガーで次の処理を実行

ホッピングウィンドウでなんかやる or セッションウィンドウでなにかやる

Coursera 模擬問題

初見 88%いけた

フォーム模擬問題

77%

kindle unlimited にある問題集

Part1 68% えー

Part2 82%

Part3 74% クソ問多し

合格した

問題集の、こんな質の低い問題出ねえだろ? と思っていたけど、まあ問題集やってて良かったな...という感想

訳も微妙だし、中華フォントだし体験は良くない...